Developer CD Series 1998 January: Mac OS SDK

home *** CD-ROM | disk | FTP | other *** search

/ Developer CD Series 1998 January: Mac OS SDK / Dev.CD Jan 98 SDK1.toast / Development Kits (Disc 1) / QuickDraw 3D / RAVE SDK 1.5 MacOS / Projects / S3V Docs / Sneak3view Documentation < prev next >

Wrap

Text File | 1997-08-14 | 33.3 KB | 775 lines | [TEXT/MPS ]

Sneak3view ========== Version 1.4 3/29/96 Introduction ============ Sneak3view is a tool for debugging and testing RAVE drawing engines. A humble objective, to be sure, but one it tackles with brio. The advantage of using Sneak3view is that it makes flipping all of RAVE's switches very easy. You can quickly change the texture maps and the background color, turn double-buffering on and off, etc., all without changing your code. Additionally, the same test is run simultaneously in two different draw contexts. This lets you compare the output of your engine with one that you know works correctly (e.g., the Apple Software rasterizer). The basic procedure for debugging your engine is as follows: write a test in C which exercises some part of your raterizer, say, textured triangles. Compile the test into Sneak3view and run the app. Select the engines and the test you want to use from the appropriate pop-up menus in the settings window. Set the RAVE state variables the way you want them and run the test. When it's complete, compare the engines' output with the image you expected. If it's not right, tweak your engine and run the test again. What You Need ==== === ==== • a PowerMac • System 7.5.1 or later • the QuickDraw 3D RAVE extension • the RAVE engines you want to test • CodeWarrior 8.0 • 2Mb - 3Mb of free memory to run Sneak3view • 16-bit or 24-bit color (unless your drawing engine supports 8-bit) • familiarity with the RAVE API Make sure you have the necessary extensions and system before running Sneak3view. It is not terribly forgiving of environments it doesn't like. IMPORTANT ========= Sneak3view now requires the Display Manager 2.0 to be present. This library should be built into every system after 7.5. Or you can add it through an extension that is available with the Display Manager SDK. What's New ====== === • The output from the timing tests is much more informative. In addition to having a better format, it now also prints out the size of the test windows and the bitdepth and size of the monitor(s). Since these values can affect the rendering speed, it's helpful to have them displayed in when comparing test runs. • Added the ability to call one test from another. This lets you group a number of tests together into one composite test so that they all get run, one after the other. "Game Scene (Every Format)" is an example of this. • Some tests can now be cancelled by typing command-period (principally the "random" tests). • The timing information that used to be printed out after every test has been removed, since it wasn't really relevant. • Fixed the bug in the timing tests that sometimes produced 1- or 2-pixel borders between the triangles. • Fixed a bug that caused textures that were 1 pixel wide or high to be mipmapped incorrectly. • Finally fixed that benign but annoying write-to-nil bug. Setting Up Sneak3view ======= == ========== The best place to put Sneak3view is simply to leave it where it is in the RAVE DDK hierarchy. That way, the CodeWarrior project's access paths will all be correct. For Sneak3view to find your engine, it must reside somewhere the RAVE manager can find it, i.e., either in the Extensions folder or the same folder as Sneak3view. What that used to mean was that every time you built a new version of your engine, you would have to copy it over to Sneak3view's folder. Fortunately, the RAVE manager will now follow aliases when looking for engines. Simply put an alias to your engine either in the Extensions folder or in Sneak3view's folder so that it will always use the latest version. If you have particular PICT files you want to use as textures or bitmaps, place them anywhere inside the Sneak3view folder. Sneak3view will search its entire folder hierarchy for PICTs when it starts up. A number of textures are included with the RAVE DDK, inside the Textures folder. Some tests, such as the Game Scene, may expect particular textures to be available when they run, so it's best to leave the existing ones where they are. Note that Sneak3view currently does not follow aliases when looking for PICT files. Settings ======== RAVE has numerous state variables and flags which affect how a drawing engine rasterizes the triangles you submit to it. These variables are controlled by Sneak3view's settings windows. Each control corresponds to some aspect of a RAVE draw context, texture or bitmap. When launched, Sneak3view opens a new, untitled settings document for you to work with. If you launch it instead by opening one or more of its documents in the Finder, Sneak3view will not open a blank document. Each settings window is a separate document. When you run a test, the values in the topmost settings window are the ones in effect. For instance, the settings window contains fields which control the size and position of the test windows. When you click on a settings window to bring it forward, the test windows will move and resize themselves to reflect the values in that settings document. The settings you select can be saved into a Sneak3view document by choosing Save or Save As... from the File menu. The position of a document window is saved when it is closed and restored the next time it is opened (assuming you didn't close it without saving the changes). Printing is not currently supported. The settings data is stored in the file's resource fork, while the test output is saved in the data fork. This means that if you change the file's type to TEXT or use an editor like Alpha which can load files of any type, then you can read the test output into a text editor. Selecting the Duplicate command from the File menu creates a new settings window that is identical to the frontmost one. This is useful when you want to quickly compare the effects of varying a few of the settings, for instance, RGB-32 vs. ARGB-16 and mipmapping on vs. off. Rather than manually changing them back and forth each time you run the test, set the controls one way (RGB-32, mipmapping on), duplicate the window, and then set a few of them the other way (ARGB-16, mipmapping off). Now you can run a test using these settings simply by clicking on the Run button in either of these windows. Normally when you close a document without saving the changes, Sneak3view makes sure that you really want to do that. However, if the document is called "Untitled Settings," its settings will automatically be recorded in "Sneak3view Prefs," inside the Preferences folder. The next time Sneak3view is launched by double-clicking, it will load those settings back into a new, untitled window. This way, if you only ever use a single window, you can just quit the application without worrying about saving the settings to a particular file. The text output section of the settings window, however, is not saved into the prefs file. Because it has so many controls, the settings window can take a long time (a second or two) to redraw. This can be quite annoying when you are single-stepping through your code and Sneak3view redraws the window every time the debugger switches back to it. Fortunately it is possible to turn off the window redraw by command-clicking in a blank part of the settings window (a good place is next to the Run button). You will hear a beep to indicate that the settings windows will not redraw themselves until you command-click again. The settings window's controls are split into five tabbed sections. To display a particular section, simply click on its tab. Each of these sections is described in detail below. Windows ------- The window settings effect the size and position of the test windows. Rather unsurprisingly, the Width and Height text fields control the width and height, respectively, of the test windows. The windows resize themselves in response to each character you type into or delete from the field. For example, if you type "2," then "0," then "0" into the width field, the test windows' width will be 2 pixels, then 20 pixels, then 200 pixels. Deleting all the text from a text field sets that field's value to 0. There are also two sets of Left and Top test fields, one under the Left Engine popup menu and one under the Right. These fields specify the positions of the top-left corners of the Left and Right test windows. (Determining which fields control which window is left(!) as an excercise for the reader.) As with the Width and Height fields, the Left and Top fields are "live," so the appropriate test window will reposition itself in response to each number you type. The values for the Left and Top fields are given in global screen coordinates. This means that if you have a second monitor to the left of the main one and position a test window on it, the window's left value will be negative. The Reset Windows button returns the test windows to their default position (on the monitor with the greatest color depth) and shape (square). Clicking this button is a quick way to make the test windows visible again, in case they appear off-screen for some reason (as might happen if you move the menu bar to a different monitor). The left and right engine pop-up menus determine which engine is called to perform a particular test. When Sneak3view starts up, it calls QAGetFirstEngine and then QAGetNextEngine to find every available RAVE drawing engine. It finds only those engines which are either in the Extensions folder or are in the same folder as the application itself. If you add a new engine while Sneak3view is running, you must quit and restart the app before it will recognize the new engine. The name of the currently-selected engine will appear in the title bar of the corresponding test window. Selecting the same engine in both pop-up menus will work just fine. Draw Context ---- ------- This section of the settings window contains eight pop-up menus which affect the type of draw context which is created for your test. Some of them control flags which are passed to QADrawContextNew to create a new draw context and some of them control state variables which are set after the context is created, but before any test is run. Many of the items in these menus represent specific RAVE constants. To see the relationships, look in the PvalDefs.r file, inside the Resources folder. Each item in a 'Pval' resource corresponds directly to an item in the menu. Device: In RAVE, you can draw to either a window or a part of memory. Selecting Window from the Device menu causes the test to draw directly to the screen. If you select Memory 16-bit or 32-bit, the test will draw into off-screen memory, which is then copied to the screen. The setting of the Device menu has important implications for what you actually end up seeing after running a test. With Window selected, the RAVE engine creates a draw context with the same bit-depth as the screen on which its test window is positioned. When you select one of the memory options, both engines draw into a context with the same bit depth, either 16 or 32, regardless of what your monitor supports. The off-screen memory is then copied to the screen using CopyBits. As an example, say you have two screens. The one on the left supports 16-bit color and the one on the right, 32-bit color. If you position one window on each monitor, the left engine will draw into a 16-bit context and the right into a 32-bit one. The pixels you see on the screen are exactly the same as the pixels the drawing engine produced. Now assume you set one monitor to 8-bit and one to 16-bit, and then select Memory 32-bit from the Device menu. Both engines will draw into a context with the same bitdepth, but what you see on the screen will vary considerably. Color resolution will be lost as CopyBits draws the 32-bit pixels onto the 8-bit and 16-bit screens. The upshot of all this is simply to be aware of the color depth of your monitor(s) and how it compares to the depth of the device type you've chosen with this menu. Note that if an engine does not support a monitor's current bit-depth and the device menu is set to Window, you will get an alert message saying that the engine does not support the current device type. This does not mean the engine cannot support the Window device type, only that it requires a different bit-depth. Either change the monitor's bit-depth or move the windows to a monitor which has an appropriate number of colors. Clipping Region: One of the parameters that is passed to QADrawContextNew is a pointer to a TQAClip. On the Macintosh, a TQAClip contains a handle to a region. The Clipping Region menu offers a choice of five different clipping regions, or none at all. The regions are constructed relative to the size of the test windows. Their effects should be clear from their names. If you want to add new types of clipping regions, you'll have to modify CTestInfo::MakeClipRegion in CTestInfo.cp, the PvalDefs.r file and the Clipping Region menu resource in Sneak3view.rsrc. Buffering: This menu controls part of the setting of the flags parameter that is passed to QADrawContextNew. It determines whether the kQAContext_DoubleBuffer bit is set or not. Z Buffering: This menu affects another part of the flags parameter, the kQAContext_DeepZ and kQAContext_NoZBuffer bits. The menu items represent the following bit combinations: None: kQAContext_NoZBuffer = 1, kQAContext_DeepZ = 0 Shallow: kQAContext_NoZBuffer = 0, kQAContext_DeepZ = 0 Deep: kQAContext_NoZBuffer = 0, kQAContext_DeepZ = 1 The remaining combination of bits (1,1) is illegal. Z Function: The required kQATag_ZFunction state variable is set through this menu. The OpenGL specific options in this menu are currently disabled. You will have to enable them with ResEdit if you're creating an OpenGL- compliant drawing engine. Perspective Z: This menu is a simple toggle for the optional kQATag_PerspectiveZ state variable. Blending: The setting of this menu controls the optional kQATag_Blend state variable. Again, the OpenGL option is disabled, and can be re-enabled with ResEdit. Antialiasing: This menu represents the value of the option kQATag_Antialias state variable. Test Arguments: This text field accepts a 255-character string, which Sneak3view makes available to your test as a C-string. You can access it with the S3TestInfo_GetArgString() function. It is up to you to decide how your tests will parse and respond to the contents of this field. Every time you change the Test popup menu, the Test Arguments field is cleared. This is done to help you avoid using an inappropriate argument string with the newly-selected test. Color/Line ---------- Background: The four text fields labeled A(lpha), R(ed), G(reen), B(lue) control the background color of the draw context (the kQATag_ColorBG_a/r/g/b state variable). The context is filled with this color before drawing begins. Acceptable values are floating point numbers between 0 and 1, although Sneak3view will set these variables to whatever values you give it. Line Width: This text field controls the required kQATag_Width state variable, which affects the width of lines and points. Acceptable values are currently between 1.0 and 128.0, but Sneak3view will set the variable to whatever number you enter. Texture ------- Through the RAVE API, you can create as many textures as a particular drawing engine can handle. However, to make it easier to test your engine on different textures, Sneak3view lets you select a single PICT file as a texture. Before the test is run, it creates a new texture from that file for each of the selected engines and sets the kQATag_Texture state variable in each draw context to point to the appropriate texture. If you write a test that requires a texture or bitmap, you must specify that prerequisite when you register the test. That way Sneak3view can alert the user that the test cannot be run until a texture is selected. The other variables that affect how a texture is drawn, such as kQATag_TextureFilter, are controlled by the checkboxes and pop-up menus in this section. Texture: When Sneak3view starts up, it searches its folder and all its subfolders for PICT files. It lists in this menu the first 80 that it finds. So the simplest way to use textures in your tests is to store them as PICTs in a folder inside Sneak3view's folder. If you want to use a file which does not appear in this menu, select the Choose... command. This opens the standard file dialog from which you can pick a PICT file. The file's name is added to the end of the pop-up menu. Also note that an alias to the texture file is recorded when the settings document is saved, so Sneak3view should be able to find the texture the next time you open the document, even if you move or rename it. Texture Format: This menu controls the value of the pixelType parameter which is passed to QATextureNew. Note that this menu's setting is independent of the PICT file's actual bit-depth. The PICT is simply drawn into an off-screen GWorld, so you can take an 8-bit PICT file with no alpha channel and create a 32-bit ARGB texture from it. However, in this case, the alpha channel will be completely blank, which means that it will be invisible unless you check Make Black Transparent. If you've stored an 8-bit alpha channel in a 32-bit PICT (using Photoshop, for instance), those alpha values will be used in the texture. It may also be possible to set the alpha bit in a 16-bit PICT and have that alpha channel used in the texture, although that has not been tested. Another way of creating an alpha channel is to use the Make Black Transparent option described below. When you select 16-bit RGB or 32-bit RGB, the drawing engine should ignore the alpha channel completely, so it shouldn't matter what you have in it. Texture Filter: This menu controls the optional kQATag_TextureFilter state variable. Texture Op: These checkboxes control the optional kQATag_TextureOp bit mask. Unchecking all of the boxes is equivalent to the kQATextureOp_None constant. Create Mipmap: This option causes Sneak3view to pass an array of images to QATextureNew, rather than just a single image, as well as setting the kQATexture_Mipmap bit in the flags parameter. The mipmaps are created using a 2 X 2 pixel square filter on the selected PICT. If you want to create your own mipmaps, you'll have to read in the PICT yourself during the test and do your own filtering on it. The alpha channel as well as the RGB channels are affected by the mipmapping process. Lock Texture: Checking this box sets the kQATexture_Lock bit in the flags parameter to QATextureNew. Detach Texture: This option determines whether QATextureDetach is called after the texture has been created. If an engine returns an error in response to QATextureDetach, Sneak3view will produce an alert and will not run the test. Make Black Transparent: This is a purely Sneak3view option which causes the app to create an alpha channel for the selected PICT. Every completely black pixel in the PICT will have its alpha channel set to 0 (transparent) and every non-black pixel's alpha channel will be set to 255 (for 32-bit) or 1 (for 16-bit). This is a useful way of quickly creating an alpha channel for a texture that does not have one. Color Table: When the texture format is set to 4-bit or 8-bit Color Lookup, the Color Table menu and the adjacent checkbox become active. Currently, the only available item on this menu is Default. With this item selected, the color table that is applied to the texture will be derived from the colors that are actually used in the PICT file. If the PICT is in 4- or 8-bit format, the file's exact color table will be used. Otherwise, QuickDraw will determine a suitable set of colors. Eventually, it will be possible to apply a color table from an arbitrary file to the current texture. Color 0 is Transparent: The call which binds a RAVE color table to a texture has a parameter which determines whether the first color in the table (index 0) is transparent. To force any pixel which has index 0 to be transparent, check this box. Otherwise, the color stored in element 0 will be drawn. Bitmap ------ Sneak3view handles bitmaps similarly to textures. You have the option of selecting one bitmap which will be created for each engine before the test is run. Bitmap: This menu is identical to the Texture pop-up menu, listing exactly the same PICT files. However, bitmaps are not required to have dimensions that are powers of 2 and may be 1-bit deep, so PICTs that are suitable for use as a bitmap are not necessarily usable as a texture. The Choose... command in both the Bitmap and Texture pop-ups is equivalent. Any file you select with it will be added to both menus. Bitmap Format: Besides the options available in the Texture Format menu, you may also choose a 1-bit alpha format. With this choice selected, every non-zero pixel in the bitmap will be colored with the RGB values which are passed into QADrawBitmap (individual tests are responsible for setting the bitmap color), while the zero-value pixels will be transparent. In this case, the Make Black Transparent option is ignored. Detach Bitmap: This checkbox is equivalent to the one for textures. It calls QABitmapDetach for the selected bitmap after it has been created. Lock Bitmap: Again, this option is identical to the texture version. It controls the value of the kQABitmap_Lock bit in the flags parameter to QABitmapNew. Make Black Transparent: Like the texture option, this checkbox causes Sneak3view to turn the black pixels in the bitmap transparent. It is ignored if Bitmap Format is set to 1-bit A. Color Table: When the bitmap format is set to 4-bit or 8-bit Color Lookup, the Color Table menu and the adjacent checkbox become active. Currently, the only available item on this menu is Default. With this item selected, the color table that is applied to the bitmap will be derived from the colors that are actually used in the PICT file. If the PICT is in 4- or 8-bit format, the file's exact color table will be used. Otherwise, QuickDraw will determine a suitable set of colors. Eventually, it will be possible to apply a color table from an arbitrary file to the current bitmap. Color 0 is Transparent: The call which binds a RAVE color table to a bitmap has a parameter which determines whether the first color in the table (index 0) is transparent. To force any pixel which has index 0 to be transparent, check this box. Otherwise, the color stored in element 0 will be drawn. Test ---- These controls are situated just below the tabbed sections and are always visible. Test: This popup-up lists all the tests you have registered in S3TestRegister. The test you select will be executed when you click the Run button. Reset Random Seed: When this option is checked, Sneak3view resets the seed used by the S3TestUtil_RandomFloat function. Any test which uses this function (or rand(), which S3TestUtil_RandomFloat calls in turn) will therefore behave exactly the same way each time it is run. This can be useful when debugging a particular test. Run: Clicking this button executes the test that is selected in the Test menu. It is also possible to run a test by typing command-R or selecting Run Test from the Test menu. If the test windows are frontmost when you select this menu item or type its shortcut, the test in the topmost settings window will the one that is executed. Before a test is run, Sneak3view ensures that certain prerequisites are met. For instance, if the test requires a texture, then you must select a texture before running that test. (A test's prerequisites are specified when the test is registered, as described in "Writing Sneak3view Tests.") You will also receive alerts if Sneak3view cannot successfully create a texture or bitmap for some reason, e.g., one of the engines does not support the selected pixel format. After the test has finished, you will receive an alert as well if it returned a failure code. Test Output: The text view at the very bottom of the settings window is where tests can print output using the S3Test_Print routine. Before a test executes, Sneak3view prints a divider line, the name of the test, and the current time and date. After a test has finished it prints another divider line. The text view is editable, so you can add your own notes amid the test output. If you want to quickly delete all of it, choose Select All from the File menu and then press the delete key. Every time you save a settings document, the output text is saved along with the settings. Test Windows ==== ======= The test windows are where your Sneak3view tests draw their output. Each window is labeled with the name of the engine which draws there. The test windows cannot be closed or hidden. The size and position of the test windows are controlled by the edit fields described above in the Windows subsection. However, it is also possible to drag a window directly. After the window has been moved, the Left and Top edit fields in the frontmost settings document are updated to reflect the test window's new position. Similarly, a test window's size can be changed by dragging its lower-right corner, even though there is no visible grow icon there. After you have resized one window, the other will adopt the same dimensions, since the test windows must always be the same size. When moving or resizing the test windows (either directly or through the settings window), make sure they do not overlap or hang off the screen. Overlapping or clipped windows will cause problems as the RAVE engines draw to the screen. When you click the Run button on a settings window or select Run Test from the Test menu, the test windows will move to the front. After the test has finished, the output in each window is saved into an off-screen bitmap with the same bit-depth as the window. This ensures that the window will redraw correctly. It also means that Sneak3view will require quite a bit of memory if you use very large, 32-bit windows. If the app cannot allocate enough space in its own heap, it will use System memory. If there is still not enough free RAM, the test output will simply not be saved. You can tell this has happened if the window does not redraw when covered and then uncovered. To reduce the memory requirements, use smaller windows and/or lower bit-depths. Another benefit of storing the test output in an off-screen bitmap is that you can save it to a file. Click on either test window to bring it forward and select Save from the File menu. You will be asked to supply a name for the file; the default name is made up of the current date and time. Each time you select Save, you will need to enter a name. (Save As... would have been more appropriate, but it's convenient to have a command-key for it.) The output is saved as a SimpleText PICT file. If the Save command is disabled, then there is not enough memory to store the test output. Saving the test output is a quick way of creating textures. Use the height and width fields to size the windows so their dimensions are a power of two (the dimensions don't have to be identical), or to any value if all you want is a bitmap. Then run a test and save the output in one of the test windows. Select Choose... from the Texture or Bitmap menus and open the PICT file you just saved. You can now use this PICT as a texture or bitmap in any tests that require one. When you resize a window after a test has been run (or switch to a settings document that has differently-sized windows), its output will be resized as well, most likely distorting the image in the process. Output Comparison ====== ========== Quite often you will be using Sneak3view to compare the output of a drawing engine that you know works correctly, such as the Apple Software rasterizer, and one which you are debugging. To quickly spot differences between the output of the two engines, you can use Sneak3view's comparison functions. Select Compare Windows from the Compare menu to compare the two windows. Both windows must have the same bitdepth, either 16-bit or 32-bit. Sneak3view will compare each pixel in the two windows and display the difference as a greyscale value in a third window. This third window will require as much memory as the other two do. When the comparison window first opens, it will display the average of the differences between the two test outputs in each channel. To display the channels separately, select one of the display options in the Compare menu, or use command-1 (red) through command-4 (alpha). If you're showing, say, the green channel in the comparison window, a completely white pixel indicates that the two outputs have an identical green component at that position. A completely black pixel means one engine used the lowest green value (0) there and the other used the highest (31 or 255). Typing command-6 or command-7 will display the actual left or right output, respectively, in the comparison window. This lets you quickly flip back and forth between one channel and the test output. The Alternate Left/Right command causes the comparison window to continually switch between the left and right output, once a second. If the comparison window is open when you run a test, the windows will be automatically re-compared after the test has finished. To stop the comparisons, simply close the window. If the comparison window is open when a composite test is run, the output will be compared after each of the sub-tests finishes. If the composite test opens a movable modal dialog asking whether you want to go on to the next test, you will be able to access the Compare menu while the dialog is open. Known Bugs ===== ==== • If the comparison window overlaps the output windows when a composite test finishes, the image of the comparison window will be saved into the test output windows. Fix: Do net let the comparison window overlap the output windows when running a composite test or close the comparison window before running it. • There appears to be a bug using 32-bit PICT files that include alpha channels as CL4 or CL8 textures or bitmaps. GetPictInfo() doesn't seem to return the correct color tables, which produces strangely-colored images. Fix: Use only PICTs with no alpha channels (less than 32-bit), or 32-bit PICTs with completely white alpha channels, as color-mapped textures and bitmaps. • At the moment, it is not possible to mipmap CL4 or CL8 textures. Fix: Write your own test and do the mipmapping yourself. • Sometimes resizing the settings window does not cause the test output area to update itself. Fix: Scroll up and then back down to redraw the text area. • If you have an extension such as Stretch which lets you resize a window by dragging any of its four sizes, the test windows will not behave correctly if you try to resize them by dragging their left or top sides. Also, you will be able to increase the width of the settings windows, which you should not be able to do. (Only the window's height should be changeable.) Fix: Don't resize these windows by dragging the left or top sides. • You will not be able to overwrite an existing file when saving a settings document, even when you click the Replace button. Fix: Delete the file manually before saving a new file with the same name. • There is no way to test the cache option for QADrawContextNew. Fix: Write a test to do it yourself. • If you collapse a test window using WindowShade and then run a test, the test's output is drawn directly to the screen. The output will, however, be saved correctly. When you expand the window again, the test output will be redrawn. Fix: Don't run a test when a test window is collapsed. • Moving the menu bar when you have multiple monitors can cause Sneak3view's settings window to open somewhere off the screen. Fix: Delete Sneak3view's prefs file and run it again. Coming Attractions ====== =========== • The ability to apply an arbitrary color table to a texture or bitmap. • Mipmapping for CL4 and CL8 textures. • A RAVE engine which will save all the triangles and textures passed to it into a file, and a test which will read that file and draw the triangles in Sneak3view. This lets you quickly generate realistic test scenes by capturing frames from existing software. • Size, depth, and path information on the selected texture or bitmap. • A test pane to display the test's prerequisites, a description of what it does, and a list of the arguments it takes. • Allow settings files to be overwritten. Questions? Comments? Bugs? ========== ========= ===== If you have any suggestions or bug reports, send them to: <mailto:brent@taurus.apple.com>